Node / ReticulumProjects / MeshChatX.git / files / SECURITY.md

Displaying Rendered • View raw • Download

If you believe you have found a security vulnerability in MeshChatX, please report it privately so it can be fixed before wider disclosure.

1. LXMF: T383838f489752fbef161c64d65e385a4e9fc74

Include enough detail to reproduce or understand the issue (what version or build you used, what you expected, what happened). Do not open a public issue for unfixed vulnerabilities.

Not security (legal, licensing, general questions): T383838legal@quad4.io or see LEGAL.md.

MeshChatX is meant to be used on trusted networks (for example at home, on a LAN, or over a VPN you control).

If you still put the web interface on the public internet, you accept much higher risk (password guessing, misconfigured TLS or proxies, automated scanning, and overload of a single-node app). If you must expose it: turn on authentication, use HTTPS with a valid certificate for the public name, restrict who can reach the port (firewall, VPN, or a reverse proxy with sensible rules), and keep the application updated. T383838/robots.txt with T383838Disallow: / is only a hint to crawlers, not protection.

The app adds rate limiting and lockout for failed logins, logging of access attempts (viewable under Debug Logs), and HttpOnly session cookies with SameSite=Lax. These measures reduce some abusebut do not make a public deployment “safe by default.”

Official release binaries and packages are built in automation on GitHub, not by hand on a laptop. Each tagged release is intended to ship:

• Installable files (for example AppImage, T383838.deb, Windows and macOS installers, Python wheels) from that tag.

• A software bill of materials (SBOM) in CycloneDX form (T383838sbom.cyclonedx.json) where the Linux release pipeline produces it, so you or your tools can see what went into the build.

• Signed provenance files (T383838*.intoto.jsonl) that cryptographically tie those binaries to the same source repository and tag on GitHub, using the industry SLSA approach and the slsa-github-generator project. New tags also get a draft GitHub release so assets can be reviewed before the release is published.

Docker images published to GitHub Container Registry are built in CI and signed with Cosign (keyless / Sigstore) so the signature can be checked against the image digest.

Optional extra signatures: If you see T383838*.cosign.bundle files next to a binary, those are additional attestations from a repository-managed signing key (when the project enables it). They are separate from the SLSA T383838*.intoto.jsonl files. Either or both may be present depending on configuration.

• Prefer official download pages or GitHub Releases for your copy of the app.

• For Docker, prefer an image referenced by digest (T383838@sha256:…) once you trust a given build, not only by a moving tag.

• If something claims to be MeshChatX but does not match published checksums or verification steps, treat it as untrusted.

• Desktop (Electron): Packaging and runtime follow Electron security guidance. ASAR integrity and hardened defaults (for example fuses that reduce risky Node integration) are part of the shipped app.

• Backend: A SHA-256 manifest of the bundled Python backend is checked on startup to detect tampering with the on-disk payload.

• Data at rest: The application can detect unexpected changes to sensitive files between runs (integrity monitoring around identities and database state).

• Web surface: Content Security Policy is applied in depth across the stack.

• Containers: Images are intended to run without root inside the container where the platform supports it.

• External code (SRI): Any WebAssembly or external JavaScript loaded at runtime (micron-parser-go, Codec2, RNode flasher libraries) is verified with SHA-384 Subresource Integrity (SRI) before execution. If a hash mismatch is detected, the code is blocked and an error is thrown. This prevents a compromised or malicious WASM binary (for example, a keylogger) from running even if an attacker replaces files on disk.

• CI: Automated pipelines (hosted on GitHub Actions) run dependency and configuration scanning (including Trivy and pip-audit on relevant paths), build checks, and security-relevant automated tests (authentication, path safety on dangerous operations, schema upgrades, backup/restore, rate limiting and access logging, and related areas). SRI integrity tests verify that external WASM/JS files match their declared hashes without regenerating the integrity manifests. CI will fail if you update these files without regenerating the integrity manifests.

• Action pinning: Third-party GitHub Actions are referenced with pinned commit SHAs in workflow definitions to reduce unexpected upgrades.

• Releases: Tagged release artifacts for Linux, Windows, and macOS are produced in CI; when the pipeline also produces Android APK and/or Flatpak bundles for the tag, those binaries are included in a separate SLSA attestation (T383838meshchatx-android-flatpak-<tag>.intoto.jsonl). SLSA Build Level 3–style provenance for those subjects is generated via the generic SLSA GitHub generator (T383838generator_generic_slsa3.yml at release v2.1.0), which satisfies the isolated builder and signed provenance expectations for that tier; distribution (draft releases, mirrors) and consumer verification remain your operational controls, as described in upstream SLSA documentation.

• Transparency logs: Many Sigstore flows write to the public Rekor log (T383838https://rekor.sigstore.dev by default). Repository-key T383838*.cosign.bundle files next to release artifacts are built without a Rekor entry; with Cosign v3+, verify them against T383838cosign.pub using T383838cosign verify-blob-attestation and T383838--insecure-ignore-tlog=true (signature and predicate are still checked against the public key). Private-repo or air-gapped policies may require different Sigstore settings; operators should align T383838COSIGN_REKOR_URL and related variables with their own governance.

• Cosign public key: When repository key-based signing is used, the public key is published in-repo as T383838cosign.pub so verifiers do not need a separate out-of-band key hunt. Key rotation: replace the GitHub secret holding the private key and update T383838cosign.pub in the repository; older releases remain verifiable with the key that was current at build time.